In networked computing systems, servers commonly manage databases having contents that are useful to clients. For example, dynamic host configuration protocol (DHCP) servers maintain information in an internal internet protocol (IP) address binding databases that other processes may need to access to meet operational or regulatory needs. Some DHCP servers allow external processes access to their internal databases in order to meet these needs, but such internal access is not always possible.
To meet the needs of external processes, in one approach, the DHCP server could be configured to transmit information from the DHCP server to an external process; however, if the external process is unavailable for a period of time or runs more slowly than the DHCP server needs to update the process, dealing with speed mismatches can be complex. When connections are lost and have to be restarted, multiple retry messages may be needed. Providing near-real-time updates may be challenging.
The DHCPv4 Leasequery, specified in Request for Comments (RFC) 4388 of the Internet Engineering Task Force, or DHCPv6 Leasequery (RFC 5007) and DHCPv6 Bulk Leasequery (RFC 5460), provide techniques to query a DHCP server for certain data. The approaches of RFC 4388 and RFC 5007/RFC 5460 require polling the DHCP server for the data. Polling approaches can be difficult to scale to large numbers of clients, if the goal is to keep an external database up-to-date with an internal DHCP IP address binding database. The result may be that synchronization cannot be achieved because too much time passes between updates, or too much time elapses between a change in the DHCP server database and clients receiving an update at the external process.
Certain commercial products provide direct access to the DHCP server's internal database. An example is Cisco Network Registrar (CNR), commercially available from Cisco Systems, Inc., San Jose, Calif. However, such access usually requires the use of proprietary techniques or data and does not easily allow for activity to be triggered by specific changes to the IP address binding database. For example, a networking engineer would have to create an extension to the CNR DHCP server that transmits DHCP binding database updates to an external process. Other products provide continuous updates as to status, but do not deal with the problems of reliability in an effective way.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.